arXivrl 509.06948V 1 [cs.DS] 23 Sep 2015 


Dynamic concurrent 
van Emde Boas array 

Konrad Kulakowski 

AGH University of Science and Technology, 
al. Mickiewicza 30, Krakow, Poland, 
konr ad. kulakowski@agh. edu .pi 


Abstract. The growing popularity of 
shared-memory multiprocessor machines 
has caused significant changes in the design 
of concurrent software. In this approach, 
the concurrently running threads commu¬ 
nicate and synchronize with each other 
through data structures in shared memory. 

Hence, the efficiency of these structures is 
essential for the performance of concurrent 
applications. The need to find new concur¬ 
rent data structures prompted the author 
some time ago to propose the cvEB array 
modeled on the van Emde Boas Tree struc¬ 
ture as a dynamic set alternative. 

This paper describes an improved version 
of that structure - the dcvEB array (Dy¬ 
namic Concurrent van Emde Boas Array). 

One of the improvements involves memory 
usage optimization. This enhancement re¬ 
quired the design of a tree which grows 
and shrinks at both: the top (root) and 
the bottom (leaves) level. Another enhance¬ 
ment concerns the successor (and predeces¬ 
sor) search strategy. The tests performed 
seem to confirm the high performance of 
the dcvEB array. They are especially visi¬ 
ble when the range of keys is significantly 
larger than the number of elements in the 
collection. 

1 Introduction 

The rapid rise in the popularity of multi-core shared- 
memory processor systems makes concurrent pro¬ 
grams increasingly common and desirable. Following 
the growing market for concurrent software, an in¬ 
creasing demand for the use of concurrent data struc¬ 
tures can be observed. Such a situation makes the 
search for new concurrent data structures particu¬ 
larly important. One of the attempts to find such a 
structure is the work [15] in which the author pro¬ 
posed the early version of the concurrent van Emde 
Boas {evEB) array. The structure presented here is 
an example of concurrent dynamic set implementa¬ 
tion providing, in addition to the standard methods 


insert()^ removef) and/ind(9, also the method succes¬ 
sor ()^ which allows users to determine the first greater 
element from the specified one. It has very good theo¬ 
retical and practical properties, as confirmed by tests 
and analyses carried out. Unfortunately, one of the 
shortcomings of that solution is the need to allocate 
all the required memory at the very beginning, as in 
the case of a regular array. Another limitation of that 
structure is the implementation of sueeessor()^ which 
in the case of massive interference with remove() op¬ 
erating in different threads might be delayed or failed 
due to the search repetition. These deficiencies led 
the author to propose a new dynamie coneurrent van 
Emde Boas {dcvEB) array, which, on the one hand, 
retains the good properties of its antecedent, and on 
the other hand is deprived of its shortcomings. Hence, 
the new structure presented in this article allocates 
and deallocates memory dynamically, depending on 
the amount of data stored in it. In addition, a new 
strategy for the successor() and predecessor() meth¬ 
ods has been adopted. The new structure, rather than 
repeating the successor or predecessor search, contin¬ 
ues searching until an appropriate element is found 
or the absence of such an element is decided. The as¬ 
sumed strategy is more robust and less susceptible to 
interference. It also seems to be more intuitive and 
justifiable in the context of user expectation. 

The article consists of several sections, where, ex¬ 
cept for introductory ones (Sec. [D-i , the dcvEB ar¬ 
ray (Subsection |4.2[ ) and its implementation (Subsec¬ 
tion |4^ are discussed. Next, the mechanisms of con¬ 
current expanding and shrinking are explained (Sub¬ 
section Other enhancements, such as dynamic 
memory allocation and the new search strategy, are 
explained (Subsections: |5.2| and |5.3[ ). Then, the suc¬ 
cessor search running time and the structure correct¬ 
ness are discussed (Section]^. The experimental re¬ 
sults are examined in Section [H The comments and 
discussion (Section and a brief summary (Section 
close the article. 

2 Background 

A dynamic set is one of the basic data structures in 
computer science. Usually, it is assumed that a dy¬ 
namic set supports the following operations: insert()^ 
delete(), search()^ minimum(), maximum()^ succes¬ 
sor () and predecessor0 [5j p. 230]. The first two of 
them are included in the category of modifying oper¬ 
ations^ while others are queries^ which do not modify 
the structure. Due to increasing demands for data 
format, different structures support dynamic set op¬ 
erations to varying degrees. In particular, good dy¬ 
namic set operation performance is provided by bal- 


anced search trees. For instance, all the dynamic set 
operations can be handled by RB-Trees [T] in a se¬ 
quential running time 0{lga), whilst van Emde Boas 
trees [55] need barely 0(lglg(a) time to complete any 
of the mentioned operations [5]. Unfortunately, tran¬ 
sition from the sequential to the concurrent objects 
is not easy [24]. Hence, many concurrent dynamic set 
implementations (e.g. HUS]) do not support all the 
dynamic set operations and instead focus on dictio¬ 
nary operations. 

The early works on the concurrent balanced search 
trees with dictionary operations began to emerge in 
the 70s |23I2| . In the subsequent years, the topic was 
studied in mm - The studies, initially focusing 
on lock strategy [2] and lock coupling cani, be¬ 
gan to deal with the relaxed (delayed) re-balancing 
[2TT9] and the non-blocking synchronization schemes 

mm- 

Skip Lish proposed by Pugh m, is an alternative 
to balanced search trees. It provides several linked 
lists arranged in a hierarchy, so that the single list 
corresponds to the set of nodes at the same depth 
in a search tree. The structure avoids additional re¬ 
balancing due to the randomized fashion of the in¬ 
sertion algorithm. SkipList is suitable for both the 
sequential and concurrent applications. Very efficient 
SkipList implementation m, based on Fraser m , is 
part of a standard Java API 5. The Java SkipList 
implementation as one of the few (the second is a 
Snap Tree Map by Bronson [3]) supports all the dy¬ 
namic set operations including successor() and pre¬ 
decessor (). 

3 van Emde Boas tree 

The tree structure proposed by van Emde Boas [55] 
is not a typical search tree. It supports all the 
dynamic set operations, such as insert()^ delete()^ 
search()^ minimum()^ maximum()^ successor() and 
predecessor0 [5j p. 230] in O(In In a). This tremen¬ 
dous speed involves the requirement that the keys 
must be unique integers in the range 0 to a — 1. 
Thus, from a practical point of view, the van Emde 
Boas (vEB) tree is something between an array and 
a search tree. Assuming that the number of stored 
elements is essentially smaller than a, the vEB tree 
is better than the array as regards the speed of suc¬ 
cessor (), predecessor0^ minimum() and maximum(). 

Of course, the efficiency of the array operations in- 
sert()^ deletef) and search() remains unchallenged re¬ 
gardless of the stored data size. In general, the vEB 
tree operates faster than the other search trees. How¬ 
ever, the strong constraint on the key values makes it 


unusable if the stored objects cannot be represented 
as unique integers. 

The key to the efficiency of the vEB tree operations 
is the uneven number of subtrees on different levels 
of the vEB tree. Thus, the root node has of sub¬ 
trees, whereas each next level of the vEB tree shrinks 
the number of children in the nodes by the square 
root. Assuming that an operation over the vEB tree 
performs 0(1) work at each level of the hierarchy, 
the running time of a method is 0(h), where h is the 
height of the vEB tree. Reducing the number of sub¬ 
trees can not be carried out indefinitely. Thus, at the 
last but one level of the tree, the nodes have at most 
two single-element subtrees, i.e. = 2. Hence, 

we obtain Ina = 2^“^, and finally h = Inina -1- 1. 
Thus, the asymptotic running time of an exemplary 
operation is 0(lnlna + 1) = O(lnlna). 

To be able to traverse each level of a tree in 0(1) 
the vEB tree methods use the arrays of references to 
the subtrees. For this reason the root node Troot needs 
to store - a^/^-element array of subtrees, 

their children T, T.arr- a^/^-element arrays of their 
subtrees, and so on. With this construction, every 
method can calculate in which subtree the given key 
can be found. For example, in the case of the root 
node, the key x is expected to be in subtree 

etc. 

To achieve 0(1) level traversing time, the more 
complex methods like successor() and predecessor() 
need further information about the subtrees. Thus, 
with every node T the next three variables are as¬ 
signed: T.max, T.min and T. summary^ where T.max^ 
T.min denote correspondingly the maximal and the 
minimal value of a key in the subtree rooted in T. 
The summary is an auxiliary search structure. Intu¬ 
itively speaking, the search() method traverses down 
the vEB tree along a well-defined path from the root 
to the given key. The successor() must deviate from 
this path to the right {predecessor() to the left). The 
decision whether to go down into the subtree accord¬ 
ing to the predetermined path or go to the right at the 
same level is taken on the basis of the value T.max. 
Thus, if T is a subtree in which, according to the 
path calculation, the key x should be stored, then 
the successor0 goes down into T only if x < T.max^ 
i.e. when the maximal key in T is greater than x. 
If x > T.max the successor() method needs to move 
horizontally to the right in search of the first non¬ 
empty subtree. Of course, such a horizontal search 
might be time consuming. For instance, the linear 
browsing may take up to 0(a^/^). In order 

to shorten the horizontal search, the same mecha¬ 
nism as in the case of the whole structure is used. 
T. summary is an auxiliary tree that holds informa- 









tion about the occupancy of the array T.arr in the 
same manner as the main tree holds the keys. Thus, 
traversing T.summary takes at most 0(lnln |T.arr|). 
In the results, the overall asymptotic running time of 
successor0 and predecessor() is 0(lnln(a). 

A good and systematic introduction into the vEB 
trees theory can be found in [5]. 

4 Construction of the dcvEB array 

4.1 Prom the vEB Tree to the dcvEB array 

One of the reasons why vEB trees are not so popu¬ 
lar in practice are space requirements [5]. The need 
to allocate one continuous block of memory in the 
root of a structure capable of holding element 

array might be inconvenient. The problem can be 
addressed in different ways EOE]- One of them im¬ 
plemented in the dcvEB array proposes the use of 
a fixed number of subtrees per node. It results in a 
worse theoretical time complexity, however, in many 
practical applications the achieved speed appears to 
be quite sufficient. For the same reason, the summary 
structure is simplified to a bit-vector aligned to the 
length of a machine-word. The use of high-speed non- 
blocking bitwise operations on the summary vector 
allows users to avoid the use of T.min and T.max. 
The logic behind some methods of the dcvEB ar¬ 
ray is also changed. For example, in the vEB tree, 
the delete () method performs one single pass from 
the top to bottom. Due to synchronization issues in 
the dcvEB array m the delete () method proceeds 
bottom-up. Similarly, successor() and predecessor() 
first reach the bottom of the tree, then start to tra¬ 
verse the tree moving up and down in search of the 
appropriate element. The dcvEB array tries to use 
the non-blocking synchronization mechanisms as of¬ 
ten as possible. For example, the get() method uses 
only the lock-free synchronization mechanisms, which 
results in its very good performance in the tests (Sec. 
[^. The only exception is the mutual synchronization 
of insert0 and deletef). In this case, in order to en¬ 
sure data consistency [m p. 373] the readers-writer 
lock El is used. 

Despite the fact that the creation of the dcvEB 
array was inspired by the vEB tree, the differences 
between these two structures seem to be fundamental. 
Therefore the dcvEB array should be treated, not as 
a concurrent extension of the sequential vEB tree but, 
as the new and original data structure. 

4.2 Structure organization 

The dcvEB and cvEB arrays can be seen as a tree 
of arrays m- Each array’s cell holds the reference 


to Array Holder (AH) - a tree node structure, which 
wraps the lower-level array or stores a specific value 
if Ais a leaf. The leaves are kept at the lower level 
of the tree. Each array corresponds to an associated 
summary - a bit vector, in which the i — th bit is 
enabled only if the appropriate array’s cell holds the 
lower level AH. Besides an array and the associated 
bit vector, every AH also contains the readers-writers 
lock object m- The leaf AH instead of an array ref¬ 
erence holds an element and an integer index value 
as its key. The value of the key determines the path 
from the root to the leaf understood as a sequence of 
positions on the various levels of the tree. The path 
positions are calculated according to the following re¬ 
current formula: = ik-i — Ipk-i * ^ Ipk = 

\ik/n^~^~^\ where n is the length of a bit vector, h - 
is the height of the tree, Ipk is the path position on the 
k — th level, io is a key of the element. A position at 
the root level Ipo is defined as Ipo = The 

dcvEB array of the height h can hold elements within 
the range [0,..., — 1]. If there is a need to store an 

element with a key greater than n^ — 1 or by removing 
the item there are no elements with the keys within 
the range ..., — 1] the tree has to be verti¬ 

cally resized. The concurrent tree resizing algorithms 
as integral parts of the insert() and remove() pro¬ 
cedures are discussed later. If the dcvEB array does 
not contain a particular element, and its key fits the 
current key range, the insert procedure recreates the 
missing AH along the path from the root to the leaf. 
Similarly, the remove procedure deletes AHs if the 
appropriated summaries are 0. 

4.3 dcvEB array methods 

The dcvEB array is designed to support all the dy¬ 
namic set methods as specified in [SJ p. 230]. Not all of 
them are extensively discussed in the article, although 
all of them are implemented^. In particular, the basics 
of the missing predecessor() method are very similar 
to successor(), which is discussed below, whilst the 
methods minimum() and maximum() have straight¬ 
forward implementation using successor() and prede- 
cess or(^ It is assumed that the stored objects are 
uniquely identified by integer keys. Thus, the key ap¬ 
pears in most of the dcvEB array methods as an 
input parameter, whilst the return value of all the 
query methods is the pair consisting of the key and 
the stored element. The presented implementation 
uses locks as well as lock-free synchronization mecha¬ 
nisms. Hence, wherever an atomic, lock-free element 
is used, an appropriate object or variable is declared 

^ The minimum can be determined by the call succes¬ 
sor ( 0), whilst maximum by the call predecessor(n^ — 1) 
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Fig. 1. dcvEB array scheme 

as atomic. The main purpose of this section is to al¬ 
low the reader to understand the general idea behind 
the presented algorithms and the data structures they 
use. For this reason some issues connected with syn¬ 
chronization and concurrency are only indicated, and 
will be discussed later. 

The methods presented above use two additional 
structures: Array Holder (Listing: [^, Array Param^ 
and one atomic common variable ap, which holds 
the current ArrayParam value. The ArrayHolder con¬ 
tains five fields: array - atomic array of references to 
the lower-level AHs^ summary - an atomic bit vector 
implemented as any integer type available on the cur¬ 
rent hardware platform, index - an atomic key value 
of the stored object, data - an atomic reference to the 
stored object, and lock - reader-writer lock object as¬ 
sociated with the given AH. 

1 ArrayHolder 

2 AtomicRefArray array 

3 Atomiclnt summary 

4 Atomiclnt index 

5 AtomicRef data 

6 RWLock lock 

Listing 1: Array Holder structure 

The second structure ArrayParam (AP) contains 
the fields: size - the number of indices assignable at 
the moment in the dcvEB array (i.e. the maximal 
object stored in the dcvEB array cannot have a key 
greater than size — 1), height - the number of levels of 


a tree implementing the dcvEB array structure except 
the last leaf level, and root - a root’s AH (Listing:]^. 

7 ArrayParam 

8 int size 

9 int height 

10 ArrayHolder root 

Listing 2: Array Parameters structure 


The current value of ArrayParam is stored in the 
common atomic variable ap. Except for initialization, 
the fields of AP are read-only, hence they do not need 
to be synchronized. 

The first presented method discussed in this sec¬ 
tion is insert() (Listing: [^. At the very beginning 
it locks the common atomic variable ap (in order to 
prevent altering the current ArrayParam reference by 
remove0)^ then it makes the local copy of the current 
array parameters (Line:[^. Next, it locks the root, 
(Line: 


13), and unlocks ap (Line: 13). 


Then, it checks whether the key value fits the cur¬ 
rent array size and, if not, it tries to extend the array 
(Listing: Lines: - EH)- Array growing is imple¬ 

mented by adding successive levels above the current 
root (Listing: |^. When the new top of the dcvEB 
array tree is ready, the algorithm tries to set it as 
the new root within the newly created ArrayParam 
record (Listing: Line: (Tt]). Then, irrespectively of 

the result of the (7AS[^ invoke, it unlocks cAP’s root 
(Listing:]^ Line: p!8|). If, due to concurrent interfer¬ 
ence with other threads, CAS fails and the common 
array parameters are not changed, the root locking 
guarded by the ap lock is repeated (Listing: Lines: 


20 - SB , and the loop condition is re-evaluated (List¬ 


ing: 1^ Line: [TB. If CAS succeeds, then cAP is up¬ 
dated (Line: [^, and the loop is interrupted. 

After the size of the array has been adapted to the 
size of a key, the algorithm traverses the tree struc¬ 
ture starting from the current root (Listing: Line: 
|2^ to the leaf. On every step of the loop while (List¬ 
ing: i Lines: [^-[ 3 ^ a subsequent level of the tree is 


visited. The loop starts from calculating the level po¬ 
sition /p, then, if it is not the top level, cAH becomes 
read locked, and the previous node pAH is unlocked 
(Listing:]^ Line: 28). Next, pAH is set to cAH^ and 


29 


cAH is atomically updated (Listing: Lines: 

3l|. This update is to set the n — Ip bit in summary 


corresponding to the Ip cell of the cAH^s array field. 
After setting the bit indicating that at Ip position in 
cAHA array there is a subtree, iteration moves to the 
lower level of the tree, i.e. the current value of cAH 


^ CAS(a,b,c) - compare and swap atomic action operat¬ 
ing under the scheme: if a = 5 then a ^ c and return 
true. Return false otherwise. 



































































is replaced by the reference to its Ip children (Listing: 

I Line: 


11 insert(key, data) 

12 apLock.rLockO ; cAP ^ ap; 

13 cAP .root .rLockO ; apLock.rUnlockO ; 

14 while (key >= cAP.size) 

15 ArrayParam newAP ^ grow(key); 

16 newAP.rLock(); 

17 tmp ^ CAS(ap,cAP,newAP); 

18 cAP. root. rUnlockO ; 

19 if not tmp then 

20 apLock.rLockO ; cAP ^ ap; 

21 cAP.root .rLockO ;apLock.rUnlockO ; 

22 else cAP ^ newAp; break; 

23 end while; 

24 cAH ^ cAP.root; cl ^ 0; pAH ^ nil; 

25 while (cl < cAP.height) 

26 Ip ^ lvlPos(cl, key); 

27 if cl 7 ^ 0 then 

28 cAH.rLockO; pAH. rUnlockO ; 

29 pAH ^ cAH; cAH.summary ^ 

30 On . . . On —Zp+1 In —ZpOn —Zp—1 • • • 0i 

31 ORbit cAH. summary; 

32 cAH ^ cAH.array[Ip]; 

33 if (cAH = nil) then 

34 cAH ^ createAHO ; 

35 CAS(pAH.array[Ip],nil,cAH) 

36 cAH ^ pAH.array[Ip]; 

37 cl ^ cl+1; 

38 end while 

39 cAH.data ^ data; cAH.index ^ key; 

40 pAH.rUnlock(); 


Listing 3: Insert method 


Of course, it is possible that the subtree has not yet 
been initialized (Listing:]^ Line: [M|). In such a case 
the new cAH is created, atomically assigned to the 
parent AH^s array when possible (Listing: Line: 

35), then due to the possible interference with an¬ 


other insert thread (but not remove thread) the final 
value of cAH is re-read from the parent cAH^s ar¬ 
ray (Listing: Line: [3^ . At the end of the loop, 

the variable determining the current level of iteration 
is incremented (Listing:]^ Line: 37). The loop ends 
when cAP is pointing at some leaf AH. Hence, at the 
end of the method both leaf AiL’s fields: data and in¬ 
dex, are updated. In the last line of insert() the leaf’s 
parent node lock is released (Listing:]^ Line: 40). 


An important routine used within the msert() 
method is grow(). It is responsible for extending the 
dcvEB array^ when it is too small to hold an ele¬ 
ment with the given key. Enlarging the array relies 
on adding additional levels above the existing root so 
that the total height h of the devEB array tree in¬ 
creases. Hence, the devEB array becomes capacious 
enough to encompass the key i.e. it requires > key. 


As a result of this operation, a new AP record is cre¬ 
ated (Listing:]^ Line: 42). Then, the grow() proce¬ 
dure calculates the appropriate new height and size 
(Listing: Lines: [^- 44). The number of levels to 

create is determined as the difference between the 
previous height and the new height of the tree (List¬ 
ing: Ra Then, the procedure starts the loop while 
(Listing: Lines: 48 - 57), and within every turn of 

the loop the new AH is generated. The first gener¬ 
ated AH becomes a new root of the tree (Listing: 

Line: 52), each further one becomes the leftmost 
child of its predecessor (Listing: Line: |^, and fi¬ 
nally the last generated AH takes the previous root 
AH as its leftmost child (Listing:]^ Line: 56). The 
sequential running time of grow() is 0(log^ a). Since 
the number of iterations of the loop while (Listing: 

Lines: 14 - 23) depends on the interferences with 


the concurrently operating delete threads, whilst the 
number of iterations of while (Listing:]^ Lines: 

^Q| ) is limited by the height h = log^ a of the tree, 
then the overall sequential running time of insert() is 
O(log^a). 

41 grow(key) 

42 nAP ^ createAPO 

43 nAP. height ^ [log ^ key] 

44 nAP.Size ^ rfCAP.hight 

45 cAP ^ ap; 

46 topSize ^ nAP.height - cAP.height 

47 cl ^ 0 

48 while (cl < topSize) 

49 cAH ^ createAHO 

50 cAH.summary ^ InOn-i-.-Oi 

51 if cl = 0 

52 nAP.root ^ cAH 

53 else 

54 pAH.array[0] ^ cAH 

55 if cl = topSize - 1 

56 cAH.array[0] ^ cAP.root 

57 pAH ^ cAH 

58 return nAP 

Listing 4: Array growing 

The next method get(), similarly to insert()^ first 
retrieves the current snapshot of the devEB array 
parameters (Listing:]^ Line: 60), then traverses the 
structure down from the root to the leaf following 
the subsequent level positions. The main difference 
between get() in the devEB array and get() from the 
previous version of the structure m is that currently 
the enabled bit in a summary does not guarantee 
the existence of the corresponding lower level array 
holder. Hence, the additional check whether the next 
AH is not actually nil is necessary (Listing: Lines: 
67 - 68). As can be seen, the sequential running time 





















of get() is determined by the loop (Listing: Lines: 
[^-[^ and is O(log^a). 

59 get(key) 

60 cAP ^ ap; cAH ^ cAP.root; cl ^ 0; 

61 while (cl < cAP.height) 

62 Ip ^ lvlPos(cl, key) 

63 if (OnOn —1 • • • On —Zp+1 In —ZpOn —Zp—1 • • • 0i 

64 ANDbit cAH. summary) = 0 

65 return nil 

66 cAH ^ cAH.array[Ip] 

67 if cAH = nil 

68 return nil 

69 cl++ 

70 end while 

71 return (cAH.data, cAH.index) 

Listing 5: Get method 


Changes resulting from the introduction of dy¬ 
namic memory allocation also affected the delete () 
method. Since insert() is able to expand the top of the 
devEB array tree and to generate missing lower level 
AHs^ then delete() needs to be able to trim the top of 
the tree and to remove redundant nodes. The delete() 
method implementation can be logically divided into 
three stages: preparing a path towards a leaf, deleting 
the leaf with the deletion propagation and cleaning, 
and the dcvEB array top trimming. Like almost all 
presented dynamic set methods, delete() also starts 
from fetching the snapshot of the current devEB ar¬ 
ray parameters (Listing: § Lines: [7^-[74|). Then, after 
the creation of the two empty tables ahol and pos for 
holding the path between the root and the node for 
disposal, the method makePath is invoked (Listing: 

Line: 77). The purpose of this method is to fill 
these tables with the subsequent AHs and their po¬ 
sitions along the way from the root to the leaf node 
being removed according to the formula for Ip^. Dur¬ 
ing the iteration, similarly to in get()^ the presence 
of the child must be checked twice. Firstly, by check¬ 
ing a summary bit vector (Listing: Lines: 87 


88 ), 


the second time by checking whether the retrieved 
subsequent AH is not nil (Listing: Line: 91). It 

is assumed that the arguments of makePath are in- 
out, which means that the changes made inside the 
method are visible outside. 


It is noteworthy that makePath may not contain a 
complete path between the root and the leaf designed 
to be disposed. This happens when there is no such 
path i.e. because the desired element has just been re¬ 
moved. In such a case the procedure stops, and leaves 
the arrays ahol and pos partially filled. In the case of 
deletef)^ not entirely filled arrays indicate that there 
is no element to delete (Listing:]^ Line:[^. Hence 
the method can finalize its operation (Listing:]^ Line: 

7 ^. 


72 delete(key) 

73 cAP ^ ap; cAH ^ cAP.root; 

74 pAH ^ nil; cl ^ 0; 

75 ahol ^ makeEmptyArray(cAP.height) 

76 pos ^ makeEmptyArray(cAP.height) 

77 makePath(key,cAP,cAH,pAH,cl,ahol,pos) 

78 if (!is_filed(ahol,cAP.height)) then 

79 return; 

80 delIntern(key,cAP,cAH,pAH,cl,ahol,pos); 

81 while (cAP != ap and rep < maxRep) 

82 deleteClean(key); rep ^ rep + 1; 

83 topTrimO; 

Listing 6: Delete method 


84 makePath(key,cAP,cAH,pAH,cl,ahol,pos) 

85 while (cl < cAP.height) 

86 Ip ^ lvlPos(cl, key); 

87 if (On . . . On —Zp+1 In —ZpOn —Zp—1 • • • 0l ANEbit 

88 cAH.summary) = 0 then break; 

89 pos [cl] ^ Ip; ahol[cl] ^ cAH; 

90 pAH ^ cAH; cAH ^ cAH.array [Ip]; 

91 if (cAH = nil) then break; 

92 cl ^ cl + I; 

93 end while 

Listing 7: makePath - delete auxiliary method 

The second and the major subroutine of delete() 
is dellntern(). In terms of the synchronization struc¬ 
ture, it is similar to the original deletef) method pre¬ 
sented in m- The need, however, for effective ar¬ 
ray holder removal caused the necessity to introduce 
a few new elements into the code of the algorithm. 
The dellntern() method is executed only if the ar¬ 
ray holder structure is correctly filled, which takes 
place only if makePath() (Listing:]^ does not break 
its while loop. Hence, at the very beginning of delln- 
tern(), it is assumed that the variable pAH refers to 
some AH from the last but one {cAP.height-1 ) level, 
whilst eAH points at the element from the last level 
containing pairs (index, data). 


Thus, after locking appropriate array holders (List- 
ing:|8) Line:[^, the stored data are overwritten by nil 
(Listing:]^ Line:|^. Afterwords dellntern() begins 
its arduous journey towards the root iterating within 
the loop while (Listing: Lines: - 

from the last but one level (Listing: 


121 L It starts 


8l Line: 100). 


First, it sets an appropriate bit in eAH’s summary to 
0 (Listing:]^ Line: 102). Therefore, the data was log¬ 
ically removed from the structure (data field is set to 
nil, index to —I, and AH is not by the parent’s sum¬ 
mary), although an appropriate array holder still ex¬ 
ists. Such an array holder will be physically removed 
only when the whole eAH’s summary is 0 (Listing: 


Line: 


107). Otherwise, if eAH’s summary is not 0, the 












previously locked nodes are released and the uiethod 
exits (Listing:]^ Lines: 103 


105). 


94 dellntern(key,cAP,cAH,pAH,cl,ahol,pos) 

95 pAH.wLockO; cAH.wLockO; 

96 cAH.data ^ nil; cAH.index ^-1; 

97 pAH ^ cAH; 

98 while (cl > 0) 

99 cAH ^ ahol[cl]; Ip ^ pos [cl]; 

100 if (cl = cAP.height - 1) 

101 cAH. summary ^ In • • • On-Zp • • • li 

102 ANDbit cAH. summary; 

103 if (cAH.summary ^ 0) 

104 pAH.wUnlockO ; cAH.wUnlockO ; 

105 return; 

106 else 

107 cAH. array ^ {nilo,..., niln-i} j 

108 else 

109 cAH.wLockO; pAH.wLockO; 

110 isSummaryAltered ^ false 

111 if (pAH.summary = 0) 

112 cAH. summary ^ In ... On-Zp • • • li 

113 ANDbit pAH. summary; 

114 isSummaryAltered ^ true 

115 if (cAH.summary = 0) 

116 cAH.array ^ {nilo,... ,niln-i} 

117 cAH.wUnlockO ; pAH.wUnlockO ; 

118 if (not isSummaryAltered) 

119 return; 

120 cl ^ cl - 1; pAH ^ cAH; 

121 end while 

Listing 8: Delete internal - delete auxiliary 
method 


122 topTrimO 

123 cAP ^ ap; 

124 while (cAP.root.summary = InOn-i-.-Oi) 

125 if (cAP.height = 1) then break; 

126 nAP ^ createAPO; 

127 nAP.height ^ cAP.height - 1; 

128 nAP.size ^ ^nAP.hight. 

129 theLonelyChild ^ 

130 cAP.root.array[0] ; 

131 if (theLonelyChild = nil) then 

132 return nil; 

133 nAP.root ^ theLonelyChild; 

134 apLock. wLockO ; cAP.root .wLockO ; 

135 if (cAP. root. summary = ln0n-i---0i) 

136 then CAS(ap,cAP,nAP); 

137 cAP.root .wUnlockO ;apLock. wUnlockO ; 

138 cAP ^ ap; 

Listing 9: TopTrim - delete auxiliary method 

The purpose of top Trim() - the last auxiliary 
method involved in delete () implementation is to cut 
the top of the dcvEB array tree if it is reduced to 
the list (Listing: |^. It is possible that, after the in- 
ternalDelete() call, the root and a few nodes below 
have only one, the leftmost, child. In such a case, the 
sequence of such vertices starting from the root needs 
to be safely removed. The top Trim() reduces the top 
of the tree iteratively. It removes only one node (root) 
in every course of the loop while (Listing: Lines: 


124 - 138). If the loop while condition is met, i.e. the 


root has only one child at the leftmost cell in the 
array, then the new AP candidate is prepared (List- 



tern (9 processes the element on the level eAP.height 
—2 or higher, then it first locks the current and previ¬ 
ous AH^s node, and next alters the eAH summary by 
removing the bit corresponding to the removed chil¬ 
dren (Listing:]^ Line: 113). As in the previous case, if 


moted to a new root candidate of the whole devEB 
array tree (Listing: Line: 133). Finally, if the ar- 


eAH summary is 0 then the child node is dereferenced 
(Listing: Lines: |115| - 1116[ ). Then, after unlocking 


cAH and pAH (Listing: Line: 117) and checking 


whether it makes sense to propagate a delete action 
towards the root (Listing:]^ Lines: 118 - 119| ) the else 
block ends. At the end of the procedure the variables 
cl (current level) and pAH (previous array holder) 
are updated (Listing: i Line: |12Q[ ). 

The next subroutine of deletef) is deleteClean(). It 
is called from deletef) just after dellntern() (Listing: 

Lines: [^ - [8^ . The main reason for which it is 
introduced is the danger of not removing all the re¬ 
quired AH when the delete action interferes with the 
insert action. The idea of deleteClean() implementa¬ 
tion and further explanations are in Subsection |5.1[ 


ray properties are not changed during the course of 
the topTrim routine (i.e. the assertion that the root 
has only one leftmost child still holds) the newly pre¬ 
pared nAP becomes the main array parameters refer¬ 
ence. The topTrim() method does not trim the trees 
shallower than the ones composed of the root and 
leaves (Listing: § Line: |125"| ). The CAS call (Listing: 

Line: |136[ ) responsible for the ArrayParam altering 
is guarded by two locks (Listing: Line: |134| ). They 
prevent a situation in which insert() adds the new 
element into the subtree rooted in the node, which 
is subject to removal by topTrim(). The sequential 
running time of delete() depends on the complexity 
of their subroutines. The first of them makePath() 
(Listing: comprises one loop while. Due to the loop 

condition (Listing: Line: it is clear that the se¬ 

quential running time of makePath() is limited by the 
height of the tree i.e. 0{\og^a). The methods delln- 






















tern(), deleteClean() and topTrim() also need at most 
to visit all the nodes on a single path between the root 
and a leaf. Therefore, their sequential running time is 
0(log^ a). Furthermore, if only one thread is up and 
running, the loop while (Listing:]^ Line: 81) executes 
only one. Thus the overall sequential running time of 
delete () equals the maximum of the running time of 
all their subcomponents, and is 0(log^(a). 


The pseudo code of the last method sueeessorf) 
was divided into two parts. The first (Listing: 
one is responsible for the attempt to reach the leaf 
AH holding the data indexed by a key. If such a 
leaf exists, it will be returned as its own successor. 
The second part (Listing: contains a loop which 

consists of two other loops, where the first internal 
loop is responsible for traversing the devEB array 
tree up, whilst the second traverses the tree down. 
Such a structure of the code in the second part cor¬ 
responds to the sueeessor()^s searching strategy. In 
other words, first the method tries to go a little bit 
higher to check where a successor leaf could be (the 
first internal loop), then tries to go towards the leaf 
in order to retrieve the stored data and key (the sec¬ 
ond internal loop). Of course, sometimes during the 
gliding down the tree the successor candidate might 
be removed. In such a case, the second loop must be 
aborted and the method once again starts to follow 
up the tree in order to find another potential succes¬ 
sor candidate. 


139 successor(key) 

140 cAP ^ ap; cAH ^ cAP.root; 

141 if (cAH. summary = 0) then return nil; 

142 pAH ^ nil; cl ^ 0; 

143 ahol ^ makeEmptyArrayCcAP.height); 

144 pos ^ makeEmptyArrayCcAP.height); 

145 makePath(key,cAP,cAH,pAH,cl,ahol,pos); 

146 if (cl = cAP.height) then 

147 cl ^ cl - 1; 

148 if (cAH 7 ^ nil) then 

149 data^ cAH.data; index ^ cAH. index; 

150 if (data ^ nil and index ^ -1) 

151 then return pair; 


Listing 10: Successor method (part I) 


At the very beginning, the suecessor() sets its own 
local copy of the array parameters (Listing: Line: 

140), then it prepares a pair of holders, eAH and 


pAH, used to traverse the structure. Then the cl vari¬ 
able indicating the visited level and two other vari¬ 
ables, ahol and pos, referring to arrays holding AHs 
and their level positions along the path from the root 


to the visited node, are defined (Listing:Lines: 140 
- |I44 ). All the newly introduced variables, including 
cAH, pAH, el, ahol and pos are initiated within the 
makePath() auxiliary method. If makePath() reaches 


the leaf level, (the condition el = cAP.height is true, 
see Fig.[^ this means that the element indexed by the 
key exists. Hence, if only the sueeessor() procedure 
manages to fetch the stored data, then the appropri¬ 
ate (data, key) pair is returned by the method (List¬ 
ing:!^ Lines: I5I). Of course, makePath() may 

not reach the leaf level (the condition el = eAP.height 
does not hold) or even if the leaf is reached, its re¬ 
moval might start before the leaf data are extracted 
(one of the following three conditions is true: eAH 
= nil, data = nil, index = -1). In such a case, the 
method control goes to the while loop (Listing: © 
and the algorithm starts to explore other successor 
candidates. 

mark: while(true) 
while (cl > 0 ) 

cAH ^ ahol [cl];Ip ^ pos [cl]; 
tmpSum — On . . . On — Zpin — Zp+1 • • • Ii 
ANDbit cAH. summary; 
if (tmpSum = 0) then cl^cl-1; 
else break; 
end while 

if (cl = - 1 ) then return nil; 
while(true) 

if (tmpSum = 0) then 
cl^cl- 1 ; goto mark; 
bp ^ mostLeftBitPos(tmpSum); 

Ip ^ IvlPos (pb) ; pos [cl] ^ Ip; 
ahol [cl] ^cAH; cAH^cAH. array [Ip] ; 
if (cAH = nil) 

cl^cl- 1 ; goto mark; 
tmpSum ^ cAH. summary; cl ^ cl + 1; 
if (cAP.height = cl) then break; 
end while 

data^ cAH.data; index ^ cAH. index; 
if (data 7 ^nil and index 7 ^-!) then 
return (data, index); 
else 

cl^cl- 1 ; goto mark; 
end while; 
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Listing 11: Successor method (part 2) 


The second part of the successor() method (List¬ 
ing: II) is responsible for traversing the structure up 


and down looking for the next successor candidate. 


The first inner loop (Listing: II, Lines: 153 - 159) 


is responsible for traversing the structure up until 
the node with the non-empty subtree further to the 
right is found or the root level is achieved, i.e. el = 
0. At the very beginning, it initiates cAH and Ip us¬ 
ing the values stored in pos and ahol (Listing: 
Line: 154). Then, it prepares the tmpSum vector so 


that the value tmpSum is non-zero, only if there are 
some bits enabled to the right of the Ip position (List- 
155 - 156). In other words, the tmp- 


mg: 


II 


Lines: 


Sum is non zero only if there exists some successor 






















candidate in some of the current level’s subtree. In 


such a case, the first loop is interrupted (Listing: 11 
Line: |158|) a nd the control goes to the if condition 


(Listing: 111 Line: |16Q[ ), otherwise the level variable 
cl is decremented and the first inner loop starts to 
examine the current node’s parent (Listing: Line: 

157). If the condition cl = -1 is true^ then there are 


no successors in the dcvEB array and the procedure 
returns nil (Listing: 


loop (Listing: 


11 


11 


Lines: 


Line: 160). The second in- 


161 - 171) starts from 


checking the bit vector tmpSum. The 0 = tmpSum 
indicates that the successor candidate is removed af¬ 
ter it has been checked (Listing: pT| L ine: 162), hence 
the loop is interrupted (Listing: |11[ Line: 163), and 
the control goes back to the beginning of the outer 
loop while (Listing: Line: [15^. If the successor is 

still there, the leftmost bit of tmpSum corresponding 
to the position of the first non-empty subtree is cal- 
Line: 


culated (Listing: 11 


164). Then, the position 


in the bit vector bp to the level position Ip is trans¬ 


formed (Listing:]^ Line: 165), and the variables pos, 
ahol and cAH are appropriately updated (Listing: fll 


IS 


Lines: p!^ - |166[ ). In particular , the value of cAH 
set to the subtree reference. Hence, if the only ele¬ 
ment in the subtree was a successor candidate, and 
unfortunately it was removed during the course of 
the second inner loop, then the value of cAH is nil 
(Line: |167[ ). In such a case, the algorithm must go 
up the tree and look for another successor candidate 
i.e. go to the beginning of the outer loop while (List- 
Line: Otherwise, the tmpSum is set to 


11 


mg:_ _ 

cAHA bit vector (Line: 169) and the current level cl 
is incremented. The second inner loop ends when the 
current level reaches the leaf level (Listing: Line: 

170). At the leaf level, the algorithm tries to fetch 


the key and data and, if it succeeds, the successor el¬ 
ement is returned. If not, the control goes back to the 
beginning of the outer loop while^ and the algorithm 
begins the journey up the tree. 

In the sequential case the successor() method first 

^Line: 

145), next a bit up (Listing: 


traverses the dcvEB array down (Listing: 10, 

Lin es:|153j-1159 ), and 


11 


then down again (Listing: ET Lines: |161|-|177D. Thus, 
during their execution, the successor() method visits 
the nodes of the dcvEB array at most Slog^a times. 
Thus, their sequential running time is 0(3 • log^ a) = 
0{\og^a). 


5 Concurrency and dynamism 


grow downwards instead of upwards. Donald Knuth 
in m writes: "There is an overwhelming tendency 
to make hand-drawn charts grow downwards instead 
of upward (...) even the word ’subtree’ (as opposed 
to ’supertree’) tends to connote a downward relation¬ 
ship". In this context, the solution adopted in the 
dcvEB array might be a little unintuitiv^ The tree 
of arrays, which in fact is the dcvEB array, on the one 
hand preserves the rule of the-root-at-the-top, on the 
other hand, it grows in both directions: downwards 
and upwards. The dcvEB array’s tree grows down¬ 
wards if the key of the inserted element is smaller 
than its current maximal capacity, and upwards if 
the key of the inserted element exceeds the current 
capacity and the tree needs to be expanded. Adding 
a new root above the current one makes the old tree 
the leftmost subtree of the new root. Hence, the new 
root summary, just after tree expansion, has the left¬ 
most bit enabled. Inserting the new element, which 
was the cause of expansion, enables another bit in 
the root summary. The tree expansion increases the 
size of the dcvEB array (understood as the range of 
the allowable keys) exponentially. Hence, adding k 
levels above the current root increases the size of a 
dcvEB array Cnew = Cold * times, where n is a 
summary size. Cold - fhe old capacity and Cnew - ftie 
new capacity. The dcvEB array tree expansion does 
not reorganize the old tree. Hence, all the existing el¬ 
ements remain in place. Because the structure of the 
subtree does not change the threads, which started to 
use the subtree before expansion, we do not have to 
worry about the changed size of the tree. The variable 
size of the tree does not affect the method of deter¬ 
mining the position of an element with the given key 
in a tree. Following the changed size of a dcvEB ar¬ 
ray (the height of the tree), the algorithm also adapts 
to the new size of the array. Hence, Ip^j^^ - the level 
position computed for the tree of height h and the 
fixed key i^ < — 1 equals Ip^^f^^^ - the level posi¬ 

tion computed after the dcvEB array tree expansion 
of r levels, where the level position Ip at the newly 
added levels is 0 i.e. Ipo = ... = Ipr-i = 0. Since the 
expansion does not change the structure of the exist¬ 
ing tree, there is no reason to make any additional 
blocking synchronization mechanisms due to the ex¬ 
pansion itself. The threads that start working before 
expansion also finish their work within the old struc¬ 
ture using the synchronization scheme as is presented 
in m- The new threads that start working after the 


5.1 Expanding and trimming 

It is widely accepted that the trees in computer sci¬ 
ence are usually drawn with the root at the top, and 


^ Of course, in Mathematics, a “tree” is just an acyclic 
and connected graph. Thus, it can expand in all direc¬ 
tions. From this perspective, adding a new root over 
the old one is not unusual. 









































expansion use the new structure, however, within the 
subtree resulting from the previous tree, they syn¬ 
chronize with the “old” threads using the locks avail¬ 
able within the subtree. Hence, the main role of syn¬ 
chronization in the case of the tree expansion is to 
provide the new threads with the latest consistent 
information about the dcvEB array tree. For this rea¬ 
son, the vital dcvEB array information, such as root 
reference, height^ and the associated size, are kept 
in the atomic global variable ap {ArrayParam struc¬ 
ture) . That is why every interface method starts from 
fetching the current array parameters (Listings: 
[^pr] Lines: |140[ ) . The dcvEB array expan¬ 


sion is implemented as part of the insert() implemen¬ 
tation (Listing:]^. The auxiliary method grow() first 
prepares the new top of the dcvEB array tree, then 
the insert0 method tries to atomically replace the 
current Array Param set with the new one prepared 
by grow(). The insert() method managed to set the 
new top of the tree. The gray triangle represents the 
tree before expansion. 

Most methods do not interfere with insert() as re¬ 
gards extending the tree. This group includes queries 
such as get(), successor(), predecessor(), min() and 
max(). If the expansion occurs after they fetch their 
own AP copy, the result they return will just not 
take into account the new elements, for which the 
key is greater than the size of the structure before 
expansion. Hence, the synchronization with respect 
to these methods can be limited to the nonblocking 
operations on atomic variables. Unfortunately, in the 
case of delete () a dcvEB array tree expansion would 
be easily disrupted by the trimming procedure. 

It is possible that, if there were no additional 
synchronization mechanism a global read-write lock 
apLock, (Listings: [^[^. In the absence of this mecha¬ 
nism it is possible that between fetching the new ar¬ 
ray parameters (Listing:]^ Line:[T^ and read-locking 
the root (Listing: Line: [T^ the top of the array 

would be trimmed. In such a case, insert() would use 
the root AH that was in fact removed from the tree, 
thus an insertion would be ineffective. Hence, the aim 
of the lock combinations {apLock read lock and AH 
read lock) used in both insert() and topTrim() is to 
prevent removal of the node when it is examined due 
to the insertion procedure. Both locks support reader- 
writer semantics. Hence, many different inserts but 
only one delete can be handled at the same time. 

Calling delete () during the expansion of the tree 
might also cause another problem that may lead (if 
not handled) in the long time perspective to perfor¬ 
mance deterioration. Namely, delete() first goes to¬ 
wards the leaf, then removes it, and next it tries to 
propagate the delete information to the higher lev¬ 


els of the tree. If the tree is extended after delete() 
fetches the current AP snapshot (Listing: Line: 

73), then the highest reachable node for delete is the 
root of the tree before expansion. Hence, dellntern() 
is not able to propagate delete information up to the 
new root and ends earlier within a subtree. In such 
a case, delete() may leave the path starting from the 
new root (and ending in the old root), which is com¬ 
posed of nodes containing false information indicating 
that their subtrees are non-empty. This issue can be 
solved in a few different ways. One of them could be 
to relax the delete operation and use query methods 
like get() or successor() to clean up the tree. An¬ 
other, proposed in this article, is to repeat delete- 
Clean() (Listing:]^ Line: 82) - the procedure, which 
discovers an undeleted path’s residues and removes 
them when needed. The method deleteClean() is very 
similar in implementation to delete() itself. However, 
other than delete(), it does not remove the element, 
but instead it tries to confirm that there is no element 
with the given key in the tree. If there is no such el¬ 
ement, but there are some AHs in the tree leading 
to them and only to them, then such nodes are re¬ 
moved and appropriate bits are disabled. The imple¬ 
mentation of the functionality of deleteClean() boils 
down to small changes in the code of the makePath() 
and dellntern() methods. Hence, taking into account 
that the Java code of the presented solution is pub¬ 
licly available, the pseudocode of deleteClean() is not 
thoroughly analyzed in the paper. An optimal num¬ 
ber of deleteClean() calls is discussed later, when the 
progress condition is considered. 

As the dcvEB array grows upwards, it is trimmed 
from the top. The trimming routine is located at the 
end of the deletef) method. It checks whether the cur¬ 
rent root has only one child at position 0, and if so, 
it attempts to remove the root. Hence, the root can 
be trimmed if the maximal element stored within the 
structure is smaller than sizejn, where size means 
the current size of the structure (the largest key that 
can be inserted into the dcvEB array without trigger¬ 
ing its extension), and n is the length of the summary 
bit vector. Trimming is implemented as the inverse 
of expansion. The only difference is that the insert() 
method tries to insert all the required nodes at once, 
whilst delete0 trims elements one by one. The root 
element after trimming is removed from the tree, and 
its only child is promoted to the new root element. 
The trimming mechanism is completely neutral for 
get(). This is partly a merit of Java, where, of course, 
nodes can be detached from the tree, but they are 
not destroyed, just as in C++ or C. Hence, as only 
get() obtains its own reference to the AP structure 
(Listing: Line: 60), and thus, the reference to the 










root, then regardless of whether any visited node is 
detached from the tree, get() may always continue 
traversing the structure. Similarly, the other query 
methods are not affected by the trimming. For in¬ 
stance, successor0^ when it obtains the root snap¬ 
shot, creates the path snapshot from the root to the 
lowest existing node on the path leading to the el¬ 
ement with the given key (Listing: p!o| Line: 145). 


The path is kept in the two auxiliary arrays ahol and 
pos. Thus, if some of the vertices stored in ahol are 
removed from the tree, they are not removed from 
ahol^ thus the successor() algorithm still has access 
to them. Hence, if there is a need to traverse the 
tree upwards, successor() is always able to do that. 
On the other hand, if some of the visited nodes have 
been actually removed from the tree, this also implies 
that there are no further successor candidates avail¬ 
able, and successor0 may finish its task earlier. For 
the same reason, trimming does not affect delete () ei¬ 
ther. Since, during the passage down, delete() creates 
its own ahol array, it has no problems with propaga¬ 
tion of the deletion status up. Of course, if some of 
the nodes referenced in ahol are removed (trimmed) 
from the tree, delete() might stop status propagation 
immediately after encountering such a node. This ob¬ 
servation, as well as an analogous situation in the case 
of the successor search, can also be a subject for fur¬ 
ther optimization. 

Two or more different top Trim () calls are synchro¬ 
nized with each other by using apLock writer lock. On 
the other hand, for the purpose of mutual topTrim() 
synchronization, a nonblocking mechanism seems to 
be sufficient. Hence, the apLock usage in this place 
is caused only by the necessity of protecting insert() 
against trimming. The writer locks used here (List¬ 
ing: El Line: |134[ ) provide top Trim() exclusive access 
to the top of the structure, which could be poten¬ 
tially dangerous for the concurrent performance of 
the structure. However, in practice, the need to trim 
the top of the dcvEB array tree is not frequent, thus 
with the performance issue in mind, it is better first 
to check whether the trimming is needed (Listing: 
Lines: |ig-l 125[ ), and if so, lock the top of the struc¬ 
ture, and before trimming, check once again (List¬ 
ing: El Line: |135[ ) whether the trimming is actually 
needed. 


5.2 Dynamic adding and removing elements 

In addition to extending and trimming the root, the 
dcvEB array tree also adds and removes elements be¬ 
low the root. This is similar to the behaviour known 
from the classical trees, where inserting or removing 
data causes the creation or deletion of appropriate 


nodes. In the presented solution, it is assumed (due 
to the desire to avoid separate handling of the unini¬ 
tialized root case) that there is always at least one 
node within the tree. This means that the root node 
exists, even if there are no other elements in the tree. 
The insert0 method creates the new element when it 
turns out that there is no AH at the specified position 
(Listing:]^ Line: 34). Adding a child AH into the par¬ 
ent array may interfere with another insert activity. 
Hence, to avoid overwriting one AH by another AH^ 
the parent’s array update is implemented as a CAS 
instruction (Listing:]^ 35). Then, if the first thread 
wins and successfully updates the parent AH’s ar¬ 
ray, the second thread just retrieves the winning AH 
(Listing: Line: 36) and continues the insertion pro¬ 

cedure with them. It is worth noting that the whole 
operation is protected in the same way as the sum¬ 
mary bit-vector update, i.e. by the AH’s reader lock 
(Listing:]^ Line: 28). Thus, there is no risk that the 
newly updated AH would be removed by delete() (af¬ 
ter execution Line: [35|), and insert() could fetch a nil 
value (Listing:]^ Line: 36). A more detailed analysis 
of the synchronization scheme used here can be found 
in [15]. 


Since operations related to the memory allocation 
and deallocation involve operating system function 
call, they are usually time-consuming. Therefore, for 
the purpose of this algorithm a kind of lazy approach 
has been adopted. Therefore, the AHs are not re¬ 
moved from the tree immediately after they become 
empty (leaves are considered empty when the fields’ 
data and index are set to nil, whilst other nodes are 
empty if their summary bit-vector equals 0). Instead, 
if some non-leaf node becomes empty, it actually re¬ 
moves all its children AHs from the memory. There¬ 
fore, the operation of deleting elements can be con¬ 
sidered as composed of two phases: the first one - 
logical removing - when data and index are set to nil 
or appropriate position in the parent’s summary bit- 
vector is zeroed, and the second one - physical remov¬ 
ing - when the AH’s reference is physically removed 
from the parent’s array and the AH record is actu¬ 
ally removed from the memory. Since the AH record 
physically removed (Listing: Lines: 107 


116) 


IS 

only when it has no siblings, the physical removing is 
likely to occur less frequently than the logical remov¬ 
ing. Both logical and physical removing use the same 
synchronization scheme as presented in [15]. Thus, 
the modified elements are always exclusively held by 
the thread performing deletion. 


















5.3 Successor search strategy 


The working scheme of the successor() method is 
composed of three phases. During the first one (List¬ 
ing: 0. the algorithm goes as far as possible towards 
the element indexed by the given key. If the element 
exists, it returns them. If not, the control goes to the 
second phase (Listing:!^ Lines: 153 - 159) in which 


the algorithm retracts until the next nonempty sub¬ 
tree is found. Then, during the third phase (Listing: 
11, Lines: 161 - 171) the algorithm goes down towards 
the element which is minimal within the detected 
nonempty subtree. If the third phase fails (the desired 
element can be removed in the meantime), then the 
control goes to the second phase and the algorithm 
starts to go upwards. The second and third phases 
are repeated as many times as needed. The main dif¬ 
ference in comparison with [15] is that, in the case 
of the necessity to repeat the second and the third 
phase, the second phase starts exactly from the same 
point where the third phase has been stopped. Thus, 
with each search failure the successor() method tries 
to look further for the next possible successor candi¬ 
date. Therefore, the number of repetitions of phase 
two and three is naturally limited by the size of the 
dcvEB array. 

Thanks to the adopted strategy, the successor el¬ 
ement will always be found if it remains in a dcvEB 
array long enough. Thus, let key be the index of el¬ 
ement X whose successor we are looking for, and let 
succ be the index oi y - some successor of x, such that 
key < succ. In such a case, if during processing the 
second part of the successor() method (Listing: 11) y 
is not removed from the dcvEB array, then the max¬ 
imal possible key of the next successor of x is succ. 
In other words, when the search algorithm detects 
the subtree (phase 2) containing y as the minimal 
element, then the algorithm seamlessly (i.e. without 
failures) reaches y. The current algorithm always re¬ 
turns the successor if it is available during the whole 
course of the successor() method. In the previous im¬ 
plementation m there was a small chance that the 
successor would not be found and successor() would 
return nil. On the other hand, the previous imple¬ 
mentation limits the number of failures that can be 
safely handled by the successor()^ whilst currently, 
the allowable number of failures is limited only by the 
current size of the structure. This raises the question 
of the actual concurrent running time of the current 
successor0 implementation. As will be shown in the 
next section (Sec. 5.4), the concurrent running time 
estimation is worse than in the sequential case. Fortu¬ 
nately, the tests carried out indicate rather high over¬ 
all efficiency of the structure rather than its suscep¬ 


tibility to the interferences and thereby performance 
deterioration. 


5.4 Successor search concurrent running 
time 


The sequential running time of all the methods pre¬ 
sented in the article is the same as in m, and equals 
0{logn(y)^ where n is the size of the summary bit 
vector, whilst a is the current size of the dcvEB 
array. The detailed arguments presented previously, 
with only minor amendments, also fit the dcvEB ar¬ 
ray. The concurrent running time estimation is much 
more complex, because, besides the code structure, 
different kinds of concurrent interactions, such as 
blocking synchronization, need to be taken into ac¬ 
count. Fortunately, some of the dcvEB array methods 
discussed in this article use only non-blocking syn¬ 
chronization mechanisms. These methods are: get() 
and successor(). Since the get() method only checks 
the presence of one, well-defined element in the ar¬ 
ray, if the check fails (no matter when the element 
has been removed), it returns nil. Hence, its concur¬ 
rent running time estimation is not affected by the 
interferences with other concurrently executed meth¬ 
ods. Thus, the concurrent running time of get() does 
not change and is 0{lognOi)- 

In contrast, in the case of successor()^ despite the 
non-blocking synchronization, every deletion of a suc¬ 
cessor candidate may increase the overall concurrent 
running time of the method. In the worst case sce¬ 
nario, the value of the successor() method is called for 
input argument 0, and the next greater element has 
the key 1. Then, if the element indexed by 1 is deleted 
just after successor() reaches the end of the loop 
(Listing: Line: |159[ ), then the deletion has been 

discovered (Listing: |ll[ Line: |173|) a nd the next iter¬ 
ation will be initiated (Listing: HI Line: |176[ ). This 
may lead to alteration of the subsequent removal and 
search attempts. The worst case scenario described 
above may occur a —1 times, forcing the successor() 
method to check every single position in the dcvEB 
array. Hence, in the worst case, the concurrent run¬ 
ning time of successor0 is 0{a). A natural question 
arises whether this slightly disappointing result can 
be improved. The easiest solution (but without any 
guarantee that the successor will be found even if 
it exists in the tree) is to limit the possible number 
of iterations of phases 2 and 3 (the loop while List¬ 
ing: Lines: |152 - 1177 ) by some empirically chosen 

constant. In such a case, the user must accept that 
(probably) very rarely the successor() method would 




















fail and never return the correct valu^ Despite the 
moderately good theoretical concurrent running time 
estimation, the current solution performs very well in 
practice. Conducted tests for the random data (Sec¬ 
tion seem to suggest that the successor() average 
running time is closer to 0{lognOi) than 0{a). 

There are also some theoretical arguments that 
may indicate in favour of 0{logna). For simplicity, 
let us assume that the dcvEB array is full (with¬ 
out nil values) and every deleted element is re¬ 
inserted into the table in a short time after re¬ 
moval. Hence, without making a big mistake, it can 
be assumed that the successor of s^ is for 

k = 1,... ,m. Thus, the collision may happen, if at 
roughly the same time, successor() processes Sk and 
delete() removes s/c+i. Assuming that both: succes¬ 
sor () and delete() process m randomly selected in¬ 
dices: (si,..., Sm) and (di,..., dm) at the same and 
equal time intervals, the likelihoocQ of the simul¬ 
taneous execution of delete(dr) and successor(sk ) 
where dr = I is \ja. Hence, the execution of 

m consecutive successor() and delete() calls may re¬ 
sult in m/a collisions. Since every collision entails 
additional tree traversal by successor(), the total ex¬ 
pected concurrent running time of m successor() calls 
is T{a,m) = mO{log^a) + (m/a)0(log^ a). Thus, 
the amortized concurrent running time of a single 
successor() call is T{a^m)/m = (1 + l/a)0{\og^a). 
In most cases a is large, for that it is safe to as¬ 
sume that T{a,m)/m ^ O(log^a). Similarly, the 
amortized concurrent running time of a single suc¬ 
cessor call for h delete threads running in parallel 
is T{a^m)/m = (1 H- h/a)0{\og^a). Thus, as long 
as h is significantly smaller than a it still holds that 
T{a,m)/m ^ 0(log^ a). At the expense of increasing 
the complexity, the above reasoning can be adapted 
to the successor0 algorithm as presented in the arti¬ 
cle. 


5.5 Correctness 

As with other concurrent data structures, the dcvEB 
array should be considered while bearing in mind 
the concurrent objects SDecificitv |18lll) . In particu- 

^ In fact, this approach provides a “limited warranty” to 
find a successor, i.e. if the iteration number is limited 
by e.g. 1000 and the successor() method is called with 
a on its input, then (even in the worst case scenario) 
there is a guarantee that if the successor exists during 
the successor0 call, then it will be found if only l3 — a< 
1000, where [3 is the key of successor. 

^ It is enough to assume that at the certain moment of 
time dr is fixed, whilst the index Sk is selected as one 
out of 1,..., A. 


lar, correctness is discussed in terms of data consis¬ 
tency (quiescent and sequential), linearizability [12], 
and the progress condition. Although these problems 
were already discussed in m, some issues need to 
be revisited due to the changes made to the origi¬ 
nal idea. One of them is linearizability. The proposed 
enhancements are of two types: the first group con¬ 
cerns growing and shrinking the dcvEB array tree, 
whilst the second concerns allocation and dealloca¬ 
tion memory for AHs. Bearing in mind the princi¬ 
ple m according to which every linearizable method 
call should appear to take effect instantaneously at 
some moment between its invocation and response, 
it is clear that the first group of enhancements do 
not affect linearizability property. In the case of in¬ 
sert () and delete(), natural linearization points are 
unlock calls just after setting the values into the leaf 
AH (Listing: |3| Line:[40|, and (Listing: [sj Lines: |104 - 
[ml). Since the code responsible for the array growth 
(inserting) or trimming (deleting) is not directly in¬ 
volved in setting or unsetting the new values in AHs, 
then the linearizability property is not affected by the 
first group of enhancements. The second group of en¬ 
hancements do not change the logic of inserting and 
deleting elements either. This is because they relate 
to the memory management rather than deleting the 
elements (elements cease to be available to the user 
at the same time as previously, i.e. the element is con¬ 
sidered to be deleted when its value in the leaf AH 
is overwritten by nil (Listing: Line:|^). In other 
words, despite the fact the memory is not immedi¬ 
ately freed after the delete() call (due to the lazy 
approach to the memory deallocation), the delete() 
method logically takes effect immediately. 

Similarly, all the query methods, including get() 
and successor(), are also linearizable i.e. they take 
effect before the query value is returned. Therefore, 
the dcvEB array is linearizable, hence, it is also qui¬ 
escently and sequentially consistent m- 

Another important criterion of concurrent object 
correctness is the progress condition. As has been 
shown in m, to preserve the progress condition the 
fair locking strategy needs to be used. Since the gen¬ 
eral synchronization scheme remains unchanged, a 
potential risk to the progress condition may come 
from the introduced enhancements. Especially dan¬ 
gerous are those loops in which fulfillment of the stop 
condition is not obvious. The first such loop is respon¬ 
sible for the dcvEB array growing (Listing: 14, Lines: 


14 - 23). The loop executes until the size of the array 


cAP.size is greater than the requested key. To prove 
that the iteration of the loop will end, note first that 
in every turn of the loop cAP.size can only grow. 
That is because cAP.root is reader-locked (Listing: 











Line: 13), hence the method delete() is not able 
to trim the dcvEB array in the meantime. Secondly, 
let us note that in every turn of the loop cAP.height 
increases by at least one. Although within the cur¬ 
rent loop insert0 tries to increase the array as far 
as necessary, it is possible that it loses the race with 
another thread, which increases the array height only 
by one. 

Another important loop with an unobvious end- 
condition is connected with the cleaning after deletion 
(Listing: Lines: 81 - 82). Although the number of 


possible iterations is limited by the maxRep constant, 
the question arises as to how many iterations are suf¬ 
ficient, i.e. how large the maxRep constant should be. 
To answer this question, let us recall that the loop is 
introduced to prevent incomplete deletion, which may 
happen if, during the element removal, the tree is ex¬ 
panded up by the insert() method. In such a case, 
since deletef) knows only the root before expansion, 
then it is able to propagate the delete information 
only up to this old root. Hence, if some nodes placed 
above the old root also need to be removed, the solu¬ 
tion proposes a re-run of the deleteClean{) method. 
It starts from the new root and checks whether for 
all the nodes on the path from the (new) root and 
the requested element, information contained in AH’s 
fields summary and AH’s array are mutually consis¬ 
tent. Hence, the question about the optimal value of 
maxRep (Listing: Line: 81) is the question about 

how many times in a row there may be a situation 
that the devEB array tree will be expanding up when 
the dellntern() or deleteClean() operations are ongo¬ 
ing. The answer depends on the domain of the array’s 
key. For instance, if the array key is Java’s Integei^ 
then assuming the length of the bit-vector as 64, the 
height of the dcvEB array tree that could hold an ob¬ 
ject with the key equal to the maximal representable 
integer is 6 = [logg 4 ( 2 ^^ — 1)]. For Java’s Long, the 
sufficient height is 11 = [logg 4 ( 2 ^^ — 1)]. Hence, for 
an array indexed by Java’s Integer, it is enough to set 
maxRep to 6, or to 11 if an array is indexed by Java’s 
Long. Of course, the exact value of maxRep depends 
on the specific data types and hardware platform and 
needs to be re-calculated for every specific implemen¬ 
tation. 

There is also one “hidden” loop, mentioned in m, 
which is not explicitly shown in pseudo-code, al¬ 
though it is important for practical implementation. 
This loop is connected with atomic update of the 
summary bit-vector within the insert() method (List¬ 
ing: i Line: [M| . Since, in most of the program- 


® The maximal integer and the long value in Java are 
MAX_INT = 2^^ - 1, MAX LONG = 2®^ - 1. 


ming languages including Java, bit operations are not 
atomic, this update has to be implemented according 
to the scheme: atomic read, modify, atomic compare 
and set (Listing: 12). 


178 while(true) 

179 s ^ cAH.summary; 

180 if OnOn —1 • • • On —Zp+1 In —ZpOn —Zp—1 • • • 0i 

181 ANDbit s > 0 

182 break; 

183 if CAS (cAH. summary, s, s ORbu 

184 OnOn —1 • • • On —Zp+1 In —ZpOn —Zp—1 • • • Oi) 

185 break; 

186 end 


Listing 12: Atomic bit-vector update scheme 

In order to prove that the bit-vector update scheme 
presented above meets the progress condition, it is 
necessary to note that eAH is reader-locked within 
the insert() method. Thus, the only concurrent mod¬ 
ifications coming from other threads that may occur 
within the code (Listing: Lines: |179| - 1184[ ) may 

enable another bit in cAH. summary (but not disable 
them). Since cAH.summary is modified (Listing: 
Line: |184[) o nly if the requested bit is not enabled 
(Listing: 11 Line: [18^ then the CAS instruction may 
fail in the worst case n times in a row, where n is 
the size of the bit vector. So, at most after n itera¬ 
tions eAH.summary contains only enabled bits, thus 


the result of the if condition (Listing: uA Lines: 180 


181) is always true. As a result, at most after n 


iterations the loop is stopped. Hence, the progress 
condition is preserved. 


6 Experimental results 

The experimental implementation of the test appli¬ 
cation together with the dcvEB array was written in 
Java 7 and has been tested on an isolated test sta¬ 
tion Intel® Core™ i7-3930K (6 cores, 12 threads, 
3.8 GHz) processor with 8 GB of operating memory. 
As in the case of the cvEB array, the results achieved 
by its successor, the dcvEB array, are very promis¬ 
ing. In many cases, the new structure turns out to be 
faster than the compared alternatives. Of course, the 
presented results are indicative and do not pretend 
to be a ranking or review. 

Since one of the advantages of the dcvEB array is to 
support all the dynamic set’s methods mentioned in 
[5l p. 230], one of the major challenges was to find an 
appropriate concurrent dynamic set implementation, 
which in addition to the standard get(), delete() and 
insert() also provides successor() and predecessor(). 
An experimental implementation of the dcvEB array 
has been written in Java. Since sometimes even small 















implementation details may affect the overall appli¬ 
cation performance, it was equally important to find 
such dynamic set solutions written in Java that have 
been identified by the authors as reference solutions. 

Besides the dcvEB array, SnapTree Map [3], Con¬ 
current Skip ListMap un, non-blocking k-ary search 
tree [4] and the synchronized java.util.TreeMap were 
selected for the tests. The structure proposed by 
Bronson et al was selected for testing because of 
the publicly available Java implementation provided 
by the author^ and the presence of support for 
successor0 and predecessor() (via Java’s Concur- 
rentNavigableMap interface). The second structure, 
Concurrent Skip ListMap, as it is implemented in re¬ 
cent Java distributions was a natural candidate for 
comparison. In m Herlihy et al. wrote about Con- 
current Skip ListMap that written by Doug Lea 

based on work by Fraser and Harris m and released 
as part of the JavaTM SE 6 platform, is the most 
effective concurrent SkipList implementation that we 
are aware of’\ The structure also implements succes¬ 
sor () and predecessor(). Moreover, its inclusion into 
the standard Java 6 platform indicates its optimality. 

The non-blocking k-ary search tree {LockFreeOST 
clas^ [4] is a new efficient tree structure modeled on 
[6] with the publicly available Java implementation. 
It does not support the successor() and predecessor() 
operations. Thus, for the test purposes, the succes¬ 
sor operation has been implemented as the iterative 
get() method calls for subsequent indices. The itera¬ 
tion ends when get() returns a non-null element or the 
iteration reaches the largest possible index that can 
be stored in the tree. In general, such an approach 
is not effective, especially when the indices are dis¬ 
tributed sparsely. Fortunately, during the tests the 
indices are distributed fairly densely, thus, one may 
expect that the performance deterioration resulting 
from using this “naive” successor search strategy is 
not too high. 

In contrast to the Concurrent Skip ListMap struc¬ 
ture, TreeMap is not even a concurrent object im¬ 
plementation. It is a globally synchronized sequential 
structure, which is included into the tests in order to 
show the difference between concurrent and sequen¬ 
tial approaches. 

In testing, there are four groups of threads: get¬ 
ters (), inserters(), removers(), and successors 
Each getter thread repeatedly calls the method get(), 
inserter thread - insertf) etc. Every thread has to per¬ 
form the same 2 : number of calls. The input parameter 

^ https: / / git hub. com / nbronson / snapt ree 
® WWW. cs. utoronto. ca/ ~tabrown/ ksts/ 

® Due to the symmetrical similarity with successor(), the 

predecessor0 method has not been subject to testing. 


key is randomly chosen from K C [0,..., x —1], where 
X is a test run parameter. The number of threads in 
groups is denoted by the letters g, i, r and s. Eor in¬ 
stance, g = 3, s = 5 means that in the given test 
run three getters and five successor searchers are in¬ 
volved. Since the number of operations per thread 
is fixed, the method performance is measured as an 
execution time according to the principle, the lower 
the value, the better the result. The execution time 
is measured per thread, thus the time of the whole 
test run is the arithmetic mean of the execution time 
of each thread involved. In other words, the thread 
execution time is the time needed by the thread to 
make 2 : calls of the given method. 

As before, the first test (Eig. measures how the 
overall thread execution time grows, when the num¬ 
ber of threads in each group is the same and in¬ 
creases. In the first test run there are four threads 
g = i = r = s = 1, m. the second one eight threads 
g = i = r = s = 2 and, finally, in the last one 100 
threads g = i = r = s = 25. Every thread performs 
^ = 500000 method calls. The results are averaged, 
so that the bad test result of one method can be com¬ 
pensated by the good result of another method. 



Fig. 2. The dcvEB array overall performance test results 
(g = i = r — s — 1,2..., 25, 2 ; = 500000 and m = 
500000) 

The best result has been achieved by the dcvEB ar¬ 
ray. Its averaged thread execution time gets 1104 ms. 
and is approximately 1.8 times better than the second 
result belonging to LockFreeOST. Both TreeMap and 
SnapTree are far behind the two previous structures. 
Such a structure of results demonstrates that the im¬ 
provements made to the original cvEB array do not 
affect its overall performance, and, on the contrary, 
they seem to be even better than in m 

In addition to the general performance comparison 
of the structures, it is interesting to compare the per¬ 
formance of the particular methods. As in ca, the 
results were averaged, so that the particular num¬ 
ber in milliseconds denotes the average time required 
by a getter, an inserter, a deleter and a successor 












searcher thread to execute half a million calls of the 
given method. 


262144 



■skiplistmap “ dcvEB array -snap tree - tree map k-ary search tree 


Fig. 3. The dcvEB array method performance test results 
= z = r = s = 1,2..., 25, z = 500000 and m = 
500000). 

The obtained results (Fig. show that the per¬ 
formance of each method varies. The very fast get() 
method and quite fast delete() and sueeessor() are 
contrasted with the average insert(). The relation¬ 
ships between the results are similar to those of |15| . 
except insert0^ which seems to be slower than be¬ 
fore. The need for memory allocation, as expected, re¬ 
sults in performance degradation. Fortunately, how¬ 
ever, despite the decrease in performance, the insert() 
method still has a comparable speed to the reference 
Concurrent Skip ListMap. Noteworthy is the very good 
result of insert0 achieved by LockFreeOST. Other 
than for the successor() method, the dcvEB array 
turns out to be the fastest. 

The dcvEB array concurrent processing efficiency 
comes from the local nature of the synchronization 
mechanisms (lock objects are spread over all the AH). 
However, it can be assumed that this “locality” may 
not be beneficial when the requested indices are close 
to each other. Hence, it is natural to test how the 
structure can handle situations when the key set is 
small. For the test purposes it was adopted that 
K = [0, ...m], where m increases starting from 10 
and ending at 776000. 

As before, for the narrow key ranges Concur¬ 
rent Skip ListMap runs similarly fast to the dcvEB ar¬ 
ray. The result of LockFreeOST does not differ signifi¬ 
cantly from those two structures. For the larger values 
of m the dominance of the dcvEB array becomes ap¬ 
parent. The slow increase in execution time is caused 
mainly by the insert() and successor() methods. With 
the increasing key range, insert() needs to allocate 
more and more memory and the distances scanned 
by successor0 get bigger. A very good result is also 



Fig. 4. The dcvEB array performance test with a variable 
key set {g — i — r — s = 2^ z — 500000 and m = 
10,100,..., 776000). 

achieved by LockFreeOST. It is almost two times bet¬ 
ter than Concurrent Skip ListMap, although it is worse 
than the dcvEB array. As in the previous test, the re¬ 
sults achieved by the other two structures are worse 
than the results of the two ranking leaders. 

The results achieved, although encouraging, have 
to be interpreted carefully. In particular, it is diffi¬ 
cult to prejudge the performance of the dcvEB array 
relative to LockFreeOST, Concurrent Skip ListMap and 
SnapTree. The last two of these structures have a very 
powerful interface providing users with much more 
functionality than the dcvEB array. Moreover, Con¬ 
current Skip ListMap and LockFreeOST are not opti¬ 
mized to integer keys, hence, in return, they can han¬ 
dle any object as the key. LockFreeOST does not sup¬ 
port natively the successor() and predecessor() oper¬ 
ations. Hence, its actual results can be better than 
those observed during the tests. Finally, SnapTree 
adopts an optimistic locking strategy, which in some 
cases can cause performance degradation. Despite the 
better results achieved by the dcvEB array than by 
the cvEB array m and the similar testing proce¬ 
dure, the performance of both structures cannot be 
directly compared. The presented tests were carried 
out on another (faster) machine than the previous 
tests, the code of the testing procedure has been im¬ 
proved, and another (new) version of Java has been 
used. It should also be noted that the dcvEB array 
used in the experiment is “flatter” than the cvEB 
array used in m, since every non-leaf node in the 
dcvEB array has 64 children, whilst in the cvEB ar¬ 
ray used in m it was less than half of that. 

7 Comments and discussion 

The presented dcvEB array is the result of improve¬ 
ments introduced into its previous version [15]. In 
























































contrast to the cvEB army, the presented structure is 
able to grow when more data need to be stored in it, 
and to shrink when the data are removed. Hence, the 
amount of occupied memory (RAM) is in relation to 
the amount of stored data. Of course, this relation¬ 
ship is not as simple as in the case of an ordinary 
binary search tree or a heap tree [5]. In those struc¬ 
tures, the amount of memory occupied depends more 
or less linearly on the amount of stored data. In the 
case of the dcvEB array, it also depends on the data 
layout. More precisely, if the smallest key is 0 and 
the largest key is — 1 (where n is the length of the 
AHs’ summary bit vector), then the dcvEB array can 
have up to 1 + n + ... + = \Ey non-leaf AHs, 

and up to — 1 leaf AHs. Whilst the number of leaf 
AHs depends only on the amount of data actually 
stored in the dcvEB array, the number of non-leaf 
AHs also depends on data distribution and the value 
of the maximal key. If the stored keys are scattered 
throughout the array, so that at all 64 positions (as¬ 
suming that n = 64) at least one element can be 
found, then the memory consumption by the dcvEB 
array is relatively high. In fact, in the worst case sce¬ 
nario even 64 times more items could be stored in 
the dcvEB array without increasing the number of 
non-leaf AHs. Reversely, if the data is indexed by the 
keys arranged one after the other, memory utilization 
is optimal and any increase in the amount of stored 
data by at least 64 keys, triggers the creation of at 
least one non-leaf AH. 

Scattered keys, although undesirable due to the use 
of extra RAM, may by beneficial to the methods using 
blocking synchronization, such as deletef) or insert(). 
The keys’ dispersion increases the chance that the 
threads operating on the dcvEB array less frequently 
block each other, which results in an increase in the 
speed of the structure. 

8 Summary 

In this paper, the author proposes the dcvEB array 
- the new concurrent implementation of the dynamic 
set structure based on the synchronization scheme 
proposed in m- The preliminary tests conducted 
using a prototype Java-based implementation of the 
structure seem to confirm that it maintains the high 
performance of the concurrent operations. The intro¬ 
duced extensions are of great practical importance. 
Thanks to them, the structure is able to dynamically 
adapt its size to the amount of stored data and in¬ 
crease or decrease the range of indices stored. There 
are also some smaller improvements, such as a new 
successor search strategy. 


The variable amount of memory used, and no limit 
on the size of the key in combination with the high 
performance of concurrent applications, can make 
this structure useful for a wide range of profession¬ 
als involved in concurrent or parallel programming. 
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